fix(keyboard): Japanese mapping - #101

Preserve the actual Windows extended-key prefix

extended_scan_code() currently infers KEYEVENTF_EXTENDEDKEY from the low scan-code byte. Those bytes are shared by ordinary and extended keys, so this changes common QWERTY input:

• Main Enter (0x1C) becomes keypad Enter (E0 1C).
• / (0x35) becomes keypad Divide (E0 35).
• Left Alt (0x38) becomes Right Alt (E0 38).
• Several numpad keys can become navigation keys.

Please obtain the extended scan code with MAPVK_VK_TO_VSC_EX and preserve its actual E0/E1 prefix. The extended flag must not be inferred from the low byte alone.

This needs regression coverage for at least main Enter, /, \, left/right Alt, keypad Enter, keypad Divide, and the numpad/navigation pairs.

Update the XTest test hook for the new function signature

key_code_to_keysym() now requires the non_normalized argument, but tests/fixtures/linux_backend_test_hooks.cpp still calls it with one argument. Consequently, the tests do not compile when XTest is available and LIBVIRTUALHID_HAVE_XTEST=1.

Please update the test hook and add coverage for both normalized and non-normalized behavior.

Do not treat the common ISO key as Japanese Ro

The required Moonlight change groups SDL_SCANCODE_NONUSBACKSLASH with Japanese SDL_SCANCODE_INTERNATIONAL1 and marks both as non-normalized. In libvirtualhid, non-normalized key code 0xE2 maps to KEY_RO, while normalized 0xE2 correctly maps to KEY_102ND.

SDL_SCANCODE_NONUSBACKSLASH is the ordinary extra key on UK and other European ISO keyboards. It is commonly used for \| or <>; it is not the Japanese Ro key.

Please keep SDL_SCANCODE_NONUSBACKSLASH normalized and mark only the genuine JIS Ro scancode as non-normalized. Add regression coverage for US QWERTY, UK ISO, German/French ISO, and Japanese JIS layouts.

Correct the Korean IME mappings in the required Moonlight change

SDL_SCANCODE_LANG1 and SDL_SCANCODE_LANG2 are Korean Hangul/English-toggle and Hanja-conversion keys. They are currently being sent as Japanese Henkan and Muhenkan key codes, which libvirtualhid then maps to KEY_HENKAN and KEY_MUHENKAN.

Please give the Korean keys distinct mappings rather than reusing the Japanese conversion-key codes. The key code plus the current Boolean flag may be insufficient to distinguish all of these language-specific keys, so the protocol representation may need to carry an unambiguous physical-key identity.